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(I) REAL PARTY IN INTEREST 

The real party in interest is British Telecommunications public limited company, 

a corporation of the country of England. 
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(II) RELATED APPEALS AND INTERFERENCES 

The appellant, the undersigned, and the assignee are not aware of any related 

appeals, interferences, or judicial proceedings (past or present), which will directly affect 
or be directly affected by or have a bearing on the Board's decision in this appeal. 
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(III) STATUS OF CLAIMS 

Claims 1-7, 9-10, 15 and 17-20 are pending. Claims 1-7, 9-10, 15 and 17-20 have 

been rejected. The rejections of claims 1-7, 9-10, 15 and 17-20 are being appealed. 
Claims 8, 1 1-14 and 16 have been canceled. No claim has been substantively allowed. 
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(IV) STATUS OF AMENDMENTS 

No amendment or response was filed subsequent to the final rejection mailed 

November 30, 2007. The current status of the claims presented in this Brief includes the 
claim amendments of the September 5, 2006 Amendment/Response (filed prior to the 
final rejection). 

However, Appellant has noticed that dependent claim 17 includes an error. To 
maintain consistency with base claim 1, claim 17 should correctly state "The method as 
in claim 1, wherein the mobil e host home agent selects an appropriate network and its 
applicable care-of address by comparing the bandwidths of the different types of 
networks to which the mobile host is selected." (Compare with the last phrase of base 
claim 1 which states " the home agent selecting an appropriate network and its applicable 
care-of address based on the available bandwidth for each type of network to which the 
mobile terminal is currently connected (emphasis added).") If base claim 1 is deemed to 
be allowable, Appellant respectfully requests correction to claim 17 as noted above. 
Similar correction would be needed to claims 18-20 which depend from base independent 
claims 9, 10 and 15, respectively, if these base claims are deemed to be allowable. 
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(V) SUMMARY OF CLAIMED SUBJECT MATTER 

A listing of each independent claim, each dependent claim argued separately and 

each claim having means plus function language is provided below including exemplary 
reference(s) to page and line number(s) of the specification. 

1 . A method of transmitting one or more data streams to a mobile terminal 
configured for simultaneous communication via a plurality of types of wireless networks, 
the method comprising: [pg. 5, 11. 16-23] 

(i) sending the one or more data streams from a correspondent host to a home 
agent located in the home network of the mobile terminal, the mobile terminal sending a 
request for a data stream to be transmitted by the correspondent host and the mobile 
terminal communicating with the home agent to transmit a network location of the 
mobile terminal to the home agent; and [pg. 5, 11. 23-29] 

(ii) forwarding the one or more data streams to the mobile terminal, [pg. 5, 11. 

29-34] 

wherein the mobile terminal sends to the home agent information about the types 
of networks to which the mobile terminal is currently connected, the available bandwidth 
for each type of network to which the mobile terminal is currently connected, and the 
mobile host's care-of address applicable for each type of network to which the mobile 
terminal is currently connected, the home agent selecting an appropriate network and its 
applicable care-of address based on the available bandwidth for each type of network to 
which the mobile terminal is currently connected, [pg. 2, 11. 11-18; pg. 9, 1. 8 to pg. 11, 1. 
30] 
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2. The method of transmitting one or more data streams to the mobile 
terminal as in claim 1, wherein in response to a change in the information about the type 
of network to which the mobile terminal is currently connected received by the home 
agent at least one of the data streams is forwarded by the home agent to a network cache, 
said at least one of the data streams being stored in the network cache until the home 
agent forwards said at least one of the data streams to the mobile terminal, [pg. 2, 11. 22- 
26; pg. 5, 11. 33-34] 

3. The method of transmitting one or more data streams to the mobile 
terminal as in claim 1 , wherein the request sent by the mobile terminal to the 
correspondent host is sent via the home agent, [pg. 2, 11. 26-27; pg. 6, 11. 5-12] 

4. The method of transmitting one or more data streams to the mobile 
terminal as in claim 1, wherein all communication from the home agent to the mobile 
terminal is routed via a foreign agent, the foreign agent being located in a subnetwork to 
which the mobile terminal is connected, [pg. 2, 11. 27-31; pg. 6, 11. 13-22] 

5. The method of transmitting one or more data streams to the mobile 
terminal as in claim 1, wherein all communication from the mobile terminal to the home 
agent is routed via a foreign agent, the foreign agent being located in a subnetwork to 
which the mobile terminal is connected, [pg. 2, 11. 27-31; pg. 6, 11. 13-22] 

6. The method of transmitting one or more data streams to the mobile 
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terminal as in claim 1, wherein in response to a change in the information about the type 
of network to which the mobile terminal is currently connected received by the home 
agent the information content of at least one of the data streams is reduced before being 
forwarded to the mobile terminal, [pg. 2, 11. 31-34; pg. 12, 11. 11-17] 

7. The method of transmitting one or more data streams to the mobile 
terminal as in claim 6, wherein the reduction of information content of the at least one of 
the data streams comprises the conversion from a first data format to a second data 
format having a lower resolution than the first data format, [pg. 2, 1. 34 - pg. 3, 1. 4; pg 
12, 11. 17-19] 

8. (canceled) 

9. A mobile communications terminal comprising: 

an interface configured for simultaneous communication via a plurality of types 
of wireless communications networks; [pg. 3, 11. 5-6; pg. 7, 11. 1 1-12] 

means for transmitting and receiving data using one or more of the network 
interfaces; [pg. 3, 11. 6-11; Figs. 2-4] 

control means operative to send messages by way of the interface to a home agent 
about the types of networks to which the mobile terminal is currently connected, the 
available bandwidth for each type of network to which the mobile terminal is currently 
connected, and the mobile host's care-of address applicable for each type of network to 
which the mobile host is connected; and [pg. 5, 11. 23-29] 
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means responsive to the home agent which selects a wireless communications 
network on which to transmit and receive data and its applicable care-of address based on 
the available bandwidth for each type of network to which the mobile terminal is 
currently connected, [pg. 9, 1. 8 - pg. 1 1, 1. 30] 

10. A communications network comprising: 

a plurality of mobile communications subnetworks, some of said mobile 
communications subnetworks having overlapping geographical coverage; and [pg. 3, 11. 
13-16; pg. 5, 11. 8-16] 

a home agent operative such that an associated mobile terminal can be in 
simultaneous communication with more than one of the plurality of mobile 
communications subnetworks; [pg. 5, 11. 16-29] 

wherein the home agent comprises a receiver for receiving from the mobile 
terminal information relating to the types of subnetworks to which the mobile terminal is 
currently connected, the available bandwidth for each type of subnetwork to which the 
mobile terminal is currently connected, and the mobile host's care-of address applicable 
for each type of subnetwork to which the mobile terminal is currently connected, the 
home agent selecting an appropriate subnetwork and its applicable care-of address based 
on the available bandwidth for each type of subnetwork to which the mobile terminal is 
currently connected, [pg. 3, 11. 14-22; pg. 9, 1. 8 to pg. 1 1, 1. 30] 

11. -14. (canceled) 
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15. A computer program product readable by a computer, tangibly embodying 
a program of instructions executable by the computer to perform a method of transmitting 
one or more data streams to a mobile terminal configured for simultaneous 
communication via a plurality of types of wireless communication channels, the method 
comprising; [pg. 5, 11. 16-23] 

(i) sending the one or more data streams from a correspondent host to a home 
agent located in a home network of the mobile terminal, the mobile terminal sending a 
request for the one or more data streams to be transmitted by the correspondent host and 
the mobile terminal communicating with the home agent to transmit the network location 
of the mobile terminal to the home agent; and [pg. 5, 11. 23-29] 

(ii) forwarding the one or more data streams to the mobile terminal, [pg. 5, 11. 

29-34] 

wherein the mobile terminal sends to the home agent information about the types 
of different communications channels to which the mobile terminal is currently 
connected, the available bandwidth for each type of communications channel to which 
the mobile terminal is currently connected, and the mobile host's care-of address 
applicable for each type of communications channel to which the mobile terminal is 
currently connected, the home agent selecting an appropriate communications channel 
and its applicable care-of address based on the available bandwidth for each type of 
communications channel to which the mobile terminal is currently connected, [pg, 2, 11. 
11-18; pg. 9, 1.8 to pg. 11,1. 30] 

16. (canceled) 
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17. The method as in claim 1 5 wherein the mobile host selects an appropriate 
network and its applicable care-of address by comparing the bandwidths of the different 
types of networks to which the mobile host is selected. 1 [pg. 11,1. 17-19] 

18. The mobile host as in claim 9, wherein the mobile host selects an 
appropriate network and its applicable care-of address by comparing the bandwidths of 
the different types of networks to which the mobile host is selected, [pg. 11,1. 17-19] 

19. The communications network as in claim 10, wherein the mobile host 
selects an appropriate network and its applicable care-of address by comparing the 
bandwidths of the different types of networks to which the mobile host is selected, [pg. 
11,1. 17-19] 

20. The computer program product as in claim 15, wherein the mobile host 
selects an appropriate communications channel and its applicable care-of address by 
comparing the bandwidths of the different types of communications channel to which the 
mobile host is selected, [pg. 11,1. 17-19] 



1 Claim 17 includes an error. To maintain consistency with base claim 1, claim 17 should correctly state 
'The method as in claim 1, wherein the mobil e ho s t home agent selects an appropriate network and its 
applicable care-of address by comparing the bandwidths of the different types of networks to which the 
mobile host is selected." (Compare with the last phrase of claim 1 which states " the home agent selecting 
an appropriate network and its applicable care-of address based on the available bandwidth for each type of 
network to which the mobile terminal is currently connected (emphasis added).") Similar comments apply 
to claims 18-20. 
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(VI) GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Whether claims 1-5, 9-10, 15 and 17-20 are anticipated under 35 U.S.C. §102 by 

Zhao et al ("Flexible Network Support for Mobility", hereinafter "Zhao"). 

Whether claims 6-7 are "obvious" under 35 U.S.C. §103 over Zhao in view of 
Kikinis (U.S. Patent No. 6,553,410). 
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(VII) ARGUMENT 

Claims 1-5. 9-10, 15 and 17-20 are not anticipated under 35 U.S.C. $102 by Zhao. 

For a reference to anticipate a claim, each element must be found, either expressly 
or under principles of inherency, in the reference. Each element of the claimed invention 
is not found in Zhao. For example, Zhao fails to disclose "wherein the mobile terminal 
sends to the home agent information about the types of networks to which the mobile 
terminal is currently connected, the available bandwidth for each type of network to 
which the mobile terminal is currently connected, and the mobile host's care-of address 
applicable for each type of network to which the mobile terminal is currently connected, 
the home agent selecting an appropriate network and its applicable care-of address based 
on the available bandwidth for each type of network to which the mobile terminal is 
currently connected" as required by independent claim 1 and its dependents. Similar (but 
not necessarily identical) comments apply to independent claims 9, 10 and 15. 

Through the above-identified claim feature, exemplary embodiments of the 
present invention relate to a mobile terminal sending information to a home agent about 
the types of networks to which it is connected, the available bandwidth for each type of 
network, and the mobile host's care-of address applicable for each type of network. Fig. 
6 and page 9, line 8 to page 10, line 30 of the originally-filed application support these 
features. The home agent then selects one of the networks based upon the bandwidth 
available for each type of network so that the selected network's applicable care-of 
address to the mobile terminal can be used. This feature is supported by, for example, 
page 1 1, lines 14-30 of the originally-filed specification. For example, the "best" 
network may be selected by the home agent by comparing bandwidths of the networks 
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and selecting the network with the highest bandwidth. The mobile host's care-of address 
applicable to the selected network can then be used. 

In contrast to the home agent selecting a network and its applicable care-of 
address based on the available bandwidth for each type of network to which the mobile 
terminal is connected, Zhao explicitly discloses "Packets are intercepted by the home 
agent and are tunneled to the care-of address selected based on the packets' destination 
address, source address and source port (emphasis added)." (See the caption of Fig. 5 of 
Zhao). A mobile host may choose to receive the packets belonging to a given flow on 
any of its interfaces by sending a flow-to-interface binding to its home agent. This flow- 
to-interface binding specifies the mobile host's care-of address(es) that the home agent 
should use to forward packets belonging to the flow. A home agent stores the received 
flow-to-interface binding in an extended binding list. Thereafter, the home agent receives 
a packet addressed to a mobile host, searches its extended binding list for an entry 
matching the corresponding fields of the packet (destination address, source address and 
source port) and forwards the packet to the associated care-of address designated in the 
extended binding list. 

There is no disclosure of Zhao's flow-to-interface binding sent from Zhao's 
mobile host to the home agent having information relating to the available bandwidth for 
each type of network to which a mobile terminal is currently connected for enabling the 
home agent to select an appropriate network and its applicable care-of address based on 
the available bandwidth . Indeed, Zhao's abstract explicitly discloses (in describing 
Zhao's system) "The other mechanism enables a mobile host to make use of multiple 
active network interfaces simultaneously and to control the selection of the most 
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desirable network interfaces for both outgoing and incoming packets for different traffic 
flows (emphasis added)." Similarly, the third paragraph of section 5.3.1 (specifically 
identified by the Final Rejection) of Zhao states "In our framework, a mobile host may 
choose to receive the packets belonging to a given flow on any of its interfaces by 
sending a Flow-to-Interface binding to its home agent. This Flow-to-interface binding 
specifies the mobile host's care-of address(es) that the home agent should use to forward 
packets belonging to the flow (emphasis added)." Zhao thus repeatedly and consistently 
discloses that it is the mobile host which instructs the home agent which network to use. 

Appellant's discussion of Zhao provided on page 1 , line 20 to page 2, line 2 in the 
background section of the present specification also describes Zhao's use of a mobile 
terminal for data routing. For example, the background section of the present application 
states "the mobile terminal will inform the home agent of the different networks to which 
it is connected and also instruct the home agent which network to use for each different 
data flow." In contrast, page 2, lines 15-18 of the specification (as amended) states, "One 
advantage of the present exemplary embodiments of the invention is that the routing of 
the data to the mobile terminal is performed by the home agent rather than the mobile 
terminal, making the terminals less complex, which should lead to smaller, cheaper 
terminals which have lower power consumption." While Zhao discloses a mobile host 
instructing a home agent which network to use, exemplary embodiments of the present 
invention enable a home agent to select an appropriate network from information relating 
to available bandwidth of each type of network to which a mobile terminal is connected. 
Moreover, Zhao fails to appreciate the explicitly described benefits (cheaper terminals 
which have lower power consumption) resulting from the present invention. 
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The Response to Arguments section (page 7) of the Final Rejection alleges that 
sections 9, 5.1 and 5.3.1 of Zhao disclose the above-noted claim limitations. Appellant 
respectfully disagrees. While section 9 of Zhao discloses "A kernel module will be 
responsible for automatically selecting the most suitable interface to use for each flow 
according to the QoS specified," this teaching does not disclose a mobile terminal 
sending to the home agent information about the available bandwidth for each type of 
network to which the mobile terminal is currently connected, the home agent selecting an 
appropriate network and its applicable care-of address based on the available bandwidth 
for each type of currently connected network. For example, there is no teaching in Zhao 
that the "kernel module" is part of the home agent, and thus no teaching that it is the 
home agent that selects the network and its applicable care-of address. Moreover, section 
9 states "For this, we have added two new socket options and have extended the Mobile 
IP protocol with new registration extensions so that a mobile host has more control over 
which interface to use to send and receive packets (emphasis added)." As described in 
other portions of Zhao, Zhao thus describes the mobile host determining which of the 
network interfaces to use, not the home agent. If anything, section 9 thus teaches away 
from the mobile terminal sending to the home agent information relating to the available 
bandwidth of each type of network to which the mobile terminal is currently connected 
and corresponding care-of addresses to the extent that it is the mobile host which selects 
the most suitable interface, not the home agent in Zhao. The entire context of the above 
sentence ("A kernel module will be responsible for automatically selecting the most 
suitable interface to use for each flow according to the QoS specified.") provided by 
section 9 thus teaches away from the above-noted claim limitation. 
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Appellant further notes that there are no specifications of the QoS which are 
specifically identified in section 9. That is, a QoS may guarantee a measure of 
performance for a transmission system based on specifications other than bandwidth such 
as latency, jitter and/or error rate. Section 5.1 of Zhao confirms that a QoS includes 
specifications other that bandwidth, such as latency. Accordingly, even assuming 
arguendo that the "kernel module" is part of the home agent, there is no disclosure that 
the available bandwidth of the QoS for each type of currently connected network forms 
the basis for selecting an appropriate network and its applicable care-of address. The 
absence of any element of the claim from the cited reference negates anticipation. See, 
e.g., Structural Rubber Prods. Co. v. Park Rubber Co., 749 F.2d 707, 715 (Fed. Cir. 
1984). Anticipation is not shown even if the differences between the claims and the prior 
art reference are insubstantial and the missing elements could be supplied by the 
knowledge of one skilled in the art. See, e.g., Structural Rubber Prods., 749 F.2d at 716- 
17. The Final Rejection's mandatory conclusion that "Selection of an interface based on 
requested QoS requirements would therefore also be based on bandwidth considerations" 
(page 7) is therefore incorrect. 

The last paragraph of section 9 states "As a future work, we plan to draw upon 
results from other projects such as the CMU Odyssey project [22] and provide mobility- 
aware applications with an API to specify flow explicitly to specific interfaces. A kernel 
module will be responsible for automatically selecting the most suitable interface to use 
for each flow according to the QoS specified." A copy of reference [22] (Noble et al., 
"Agile Application - Aware Adaptation for Mobility." in Proceedings of the 16 th ACM 
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Symposium on Operating Systems Principles, 1997) is attached in (IX) Evidence 
Appendix to this Brief. 

The Odyssey system in Noble is only described as an architecture built on top of 
an operating system, or kernel , located on a client device (i.e., a mobile agent). The 
system relates to centralized monitoring and resource management in relation to 
application demands (see the third paragraph of section 2.3, and the last paragraph of 
section 6), and does not suggest how the arrangement might be applied or modified in 
any way to operate on a home agent instead of a mobile agent. Figure 2 in Noble clearly 
shows the Odyssey architecture, which when read in conjunction with the general 
teachings in the description, make very clear that the Odyssey system and the kernel on 
which it is based are located on the mobile client, and not at some central server of a 
home agent. Figures 4, 5 and 6 also support this, showing the "viceroy" components of 
the Odyssey system to be positioned within the (mobile) client. There is absolutely no 
discussion in Noble of how the arrangement could be modified to operate on a separate 
server or agent, other than the mobile client. Again, the key is that the Odyssey system 
runs on the client device and is designed to support centralized resource management for 
applications running on that same mobile device. Noble therefore only teaches resource 
management on centralized level at a particular mobile device/client (whether that be the 
"kernel" described in Noble or the general Odyssey system). 

Secondly, and equally important, Noble's description in relation to bandwidth are 
merely about how the bandwidth of a connection can be monitored by the Odyssey 
system on the mobile device, and how the interactions with the applications on the 
mobile device can be adjusted accordingly. Noble thus describes systems that are 
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reactive in relation to bandwidth considerations, and never is there any discussion or 
suggestion that somehow a network might be selected based on an associated bandwidth. 
Noble describes application adaptation in response to resource issues, rather than actually 
controlling any resources such as network connections or bandwidth. 

The last sentence of section 9 states "We are also looking into the possibility of 
merging interface selection into the Mobile Policy Table." The Mobile Policy Table in 
Zhao is first discussed on page 149 and in Table 1 . Here, the table is described as being 
"used by our mobile hosts...." (See page 149, first paragraph under Table 1). There is no 
suggestion that the table would or could be used by some home agent instead of the 
mobile host as clearly described. 

Claims 6-7 are not "obvious" under 35 U.S.C. §103 over Zhao in view of Kikinis 
(U.S. '410) . 

Since claims 6-7 depend from claim 1, all of the comments made above with 
respect to Zhao apply equally to these claims. Kikinis, while disclosing translating data 
from Internet sources into a reduced-content form adapted specifically to a client device, 
fails to remedy the above-described deficiencies of Zhao. In particular Kikinis fails to 
teach or suggest "wherein the mobile terminal sends to the home agent information about 
the types of networks to which the mobile terminal is currently connected, the available 
bandwidth for each type of network to which the mobile terminal is currently connected, 
and the mobile host's care-of address applicable for each type of network to which the 
mobile terminal is currently connected, the home agent selecting an appropriate network 
and its applicable care-of address based on the available bandwidth for each type of 
network to which the mobile terminal is currently connected" as required by independent 
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claim 1 and its dependents. Accordingly, even if Zhao and Kikinis were combined as 
proposed by the Final Rejection, the combination would not have taught or suggested all 
of the claim limitations. 



CONCLUSION 

In conclusion it is believed that the application is in clear condition for allowance; 
therefore, early reversal of the Final Rejection and passage of the subject application to 
issue are earnestly solicited. 



Respectfully submitted, 




RYM:sl 

901 North Glebe Road, 1 1th Floor 
Arlington, VA 22203-1808 
Telephone: (703) 816-4000 
Facsimile: (703)816-4100 



21 



TITMUSS et al 
Application No. 09/868,221 
July 2, 2007 

(VIII) CLAIMS APPENDIX 

1 . A method of transmitting one or more data streams to a mobile terminal 

configured for simultaneous communication via a plurality of types of wireless networks, 
the method comprising: 

(i) sending the one or more data streams from a correspondent host to a home 
agent located in the home network of the mobile terminal, the mobile terminal sending a 
request for a data stream to be transmitted by the correspondent host and the mobile 
terminal communicating with the home agent to transmit a network location of the 
mobile terminal to the home agent; and 

(ii) forwarding the one or more data streams to the mobile terminal, 
wherein the mobile terminal sends to the home agent information about the types 

of networks to which the mobile terminal is currently connected, the available bandwidth 
for each type of network to which the mobile terminal is currently connected, and the 
mobile host's care-of address applicable for each type of network to which the mobile 
terminal is currently connected, the home agent selecting an appropriate network and its 
applicable care-of address based on the available bandwidth for each type of network to 
which the mobile terminal is currently connected. 

2. The method of transmitting one or more data streams to the mobile 
terminal as in claim 1 , wherein in response to a change in the information about the type 
of network to which the mobile terminal is currently connected received by the home 
agent at least one of the data streams is forwarded by the home agent to a network cache, 
said at least one of the data streams being stored in the network cache until the home 
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agent forwards said at least one of the data streams to the mobile terminal. 

3. The method of transmitting one or more data streams to the mobile 
terminal as in claim 1 , wherein the request sent by the mobile terminal to the 
correspondent host is sent via the home agent. 

4. The method of transmitting one or more data streams to the mobile 
terminal as in claim 1, wherein all communication from the home agent to the mobile 
terminal is routed via a foreign agent, the foreign agent being located in a subnetwork to 
which the mobile terminal is connected. 

5. The method of transmitting one or more data streams to the mobile 
terminal as in claim 1, wherein all communication from the mobile terminal to the home 
agent is routed via a foreign agent, the foreign agent being located in a subnetwork to 
which the mobile terminal is connected. 

6. The method of transmitting one or more data streams to the mobile 
terminal as in claim 1 , wherein in response to a change in the information about the type 
of network to which the mobile terminal is currently connected received by the home 
agent the information content of at least one of the data streams is reduced before being 
forwarded to the mobile terminal. 

7. The method of transmitting one or more data streams to the mobile 
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terminal as in claim 6, wherein the reduction of information content of the at least one of 
the data streams comprises the conversion from a first data format to a second data 
format having a lower resolution than the first data format. 

8. (canceled) 

9. A mobile communications terminal comprising: 

an interface configured for simultaneous communication via a plurality of types 
of wireless communications networks; 

means for transmitting and receiving data using one or more of the network 
interfaces; 

control means operative to send messages by way of the interface to a home agent 
about the types of networks to which the mobile terminal is currently connected, the 
available bandwidth for each type of network to which the mobile terminal is currently 
connected, and the mobile host's care-of address applicable for each type of network to 
which the mobile host is connected; and 

means responsive to the home agent which selects a wireless communications 
network on which to transmit and receive data and its applicable care-of address based on 
the available bandwidth for each type of network to which the mobile terminal is 
currently connected. 

1 0. A communications network comprising: 

a plurality of mobile communications subnetworks, some of said mobile 
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communications subnetworks having overlapping geographical coverage; and 

a home agent operative such that an associated mobile terminal can be in 
simultaneous communication with more than one of the plurality of mobile 
communications subnetworks; 

wherein the home agent comprises a receiver for receiving from the mobile 
terminal information relating to the types of subnetworks to which the mobile terminal is 
currently connected, the available bandwidth for each type of subnetwork to which the 
mobile terminal is currently connected, and the mobile host's care-of address applicable 
for each type of subnetwork to which the mobile terminal is currently connected, the 
home agent selecting an appropriate subnetwork and its applicable care-of address based 
on the available bandwidth for each type of subnetwork to which the mobile terminal is 
currently connected. 

11.-14. (canceled) 

15. A computer program product readable by a computer, tangibly embodying 
a program of instructions executable by the computer to perform a method of transmitting 
one or more data streams to a mobile terminal configured for simultaneous 
communication via a plurality of types of wireless communication channels, the method 
comprising: 

(i) sending the one or more data streams from a correspondent host to a home 
agent located in a home network of the mobile terminal, the mobile terminal sending a 
request for the one or more data streams to be transmitted by the correspondent host and 
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the mobile terminal communicating with the home agent to transmit the network location 
of the mobile terminal to the home agent; and 

(ii) forwarding the one or more data streams to the mobile terminal, 
wherein the mobile terminal sends to the home agent information about the types 
of different communications channels to which the mobile terminal is currently 
connected, the available bandwidth for each type of communications channel to which 
the mobile terminal is currently connected, and the mobile host's care-of address 
applicable for each type of communications channel to which the mobile terminal is 
currently connected, the home agent selecting an appropriate communications channel 
and its applicable care-of address based on the available bandwidth for each type of 
communications channel to which the mobile terminal is currently connected. 

16. (canceled) 

1 7. The method as in claim 1 , wherein the mobile host selects an appropriate 
network and its applicable care-of address by comparing the bandwidths of the different 
types of networks to which the mobile host is selected. 

18. The mobile host as in claim 9, wherein the mobile host selects an 
appropriate network and its applicable care-of address by comparing the bandwidths of 
the different types of networks to which the mobile host is selected. 

19. The communications network as in claim 10, wherein the mobile host 
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selects an appropriate network and its applicable care-of address by comparing the 
bandwidths of the different types of networks to which the mobile host is selected. 



20. The computer program product as in claim 15, wherein the mobile host 
selects an appropriate communications channel and its applicable care-of address by 
comparing the bandwidths of the different types of communications channel to which the 
mobile host is selected. 
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Abstract 

In this paper we show that application-aware adaptation, a 
collaborative partnership between the operating system and 
applications, offers the most general and effective approach 
to mobile information access. We describe the design of 
Odyssey, a prototype implementing this approach, and show 
how it supports concurrent execution of diverse mobile ap- 
plications. We identify agility as a key attribute of adap- 
tive systems, and describe how to quantify and measure it. 
We present the results of our evaluation of Odyssey, indi- 
cating performance improvements up to a factor of 5 on a 
benchmark of three applications concurrently using remote 
services over a network with highly variable bandwidth. 

1 Introduction 

Adaptation is the key to mobility. Only through alertness and 
prompt reactions can a mobile client offer acceptable service in 
spite of the many problems that plague its existence. These in- 
clude unpredictable variation in network quality, wide disparity in 
the availability of remote services, limitations on local resources 
imposed by weight and size constraints, concern for battery power 
consumption, and lowered trust and robustness resulting from ex- 
posure and motion [5, 15,31]. 

Once the need for adaptation is recognized, many questions fol- 
low. What form should such adaptation take? Which system com- 
ponents should bear responsibility for adaptation? How does one 
characterize the adaptive capability of a mobile client? How does 
one compare alternative designs from the perspective of adaptation? 

We present our answers to these and related questions in this pa- 
per. We describe the design and implementation of a software plat- 
form called Odyssey, and show how it provides effective support 
for concurrent execution of diverse mobile applications. We iden- 
tify agility as a key attribute of adaptive systems, and describe how 
to quantify and measure it. Finally, we present the results of our 
evaluation of the Odyssey prototype to confirm the benefits of our 
approach. These results indicate performance improvements up to a 
factor of 5 on a benchmark of three applications concurrently using 
remote services over a network with highly variable bandwidth. 
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2 Design Rationale 

Odyssey is a set of extensions to the NetBSD operating system to 
support adaptation for a broad range of mobile information access 
applications. These applications execute on mobile clients but read 
or update remote data on servers. Our goal in building Odyssey is 
to enable mobile scenarios such as the following one. 

2.1 Motivation 

Consider a hypothetical scenario in which a tourist with a wearable 
computer running Odyssey is walking in an urban setting. A wire- 
less overlay network [16] provides the computer with a variety of 
connection alternatives, which differ in bandwidth, coverage, cost, 
and reliability. The higher-bandwidth alternatives are more sensi- 
tive to fading and signal loss as the user moves in and out of the 
radio shadows of buildings. 

As he walks, the user interacts with his computer through spoken 
commands; he receives output through a head-mounted display or 
synthesized speech. The speech software exploits remote compute 
servers when connected, but is capable of degraded interactions us- 
ing a tiny vocabulary when disconnected. One application provides 
a video narration of local history, with content delivered from a re- 
mote server. Another application is a Web browser that can respond 
to queries about the local environment. 

Odyssey monitors resources such as bandwidth, CPU cycles, and 
battery power, and interacts with each application to best exploit 
them. For example, when high-bandwidth connectivity is lost due 
to a radio shadow, Odyssey detects the change and notifies inter- 
ested applications. The video application responds by skipping 
frames, thus displaying fewer frames per minute, while the Web ap- 
plication responds by displaying degraded versions of large images. 
When the user emerges from the radio shadow, Odyssey detects 
a substantial improvement in bandwidth and notifies applications. 
They then revert to their original behaviors. 

Although the user is aware of changing application behavior dur- 
ing his walk, he does not have to initiate adaptation or be involved 
in its details. Rather, he can delegate these decisions to Odyssey, 
confident that reasonable tradeoffs will be made. 

While mobile scenarios such as this motivated the design of 
Odyssey, its benefits may be valuable in a broader context. For ex- 
ample, large bandwidth variations can arise in wide-area networks 
with fluctuating loads. The adaptation supported by Odyssey can 
be valuable in coping with such variation. 

2.2 Fidelity 

As the example in the previous section illustrates, the data accessed 
by an Odyssey application may be stored in one or more general- 
purpose repositories such as file servers, SQL servers, or Web 
servers. Alternatively, it may be stored in more specialized reposi- 
tories such as video libraries, query-by-image-content databases, or 
back ends of geographical information systems. 

The constraints of mobility complicate data access from such 
servers. Ideally, a data item available on a mobile client should be 
indistinguishable from that available to the accessing application if 



it were to be executed on the server storing that item. But this corre- 
spondence may be difficult to preserve as resources become scarce; 
some form of degradation may be inevitable. We define fidelity as 
the degree to which data presented at a client matches the reference 
copy at the server. 

Fidelity has many dimensions. One well-known, universal di- 
mension is consistency. Systems such as Coda [18, 32], Ficus [28] 
and Bayou [38] expose potentially stale data to applications when 
network connectivity is poor or nonexistent. Other dimensions of 
fidelity depend on the type of data in question. For example, video 
data has at least two additional dimensions: frame rate and image 
quality of individual frames. Spatial data, such as topographical 
maps, has dimensions of minimum feature size or resolution. For 
telemetry data, appropriate dimensions include sampling rate and 
timeliness. The dimensions of fidelity are natural axes of adaptation 
for mobility. However, the adaptation cannot be solely determined 
by the type of data; it also depends on the application. Different ap- 
plications using the same data may make different tradeoffs among 
dimensions of fidelity. 

A key goal of Odyssey is to provide a framework within which 
diverse notions of fidelity can easily be incorporated. Our focus 
on mobile information access allows us to bound this diversity to 
manageable proportions. Specifically excluded from our purview 
are applications that involve stringent real-time constraints, such as 
video conferencing and multi-client interactive games. 

Supporting multiple levels of fidelity complicates the task of 
evaluation. Since adaptive applications trade fidelity of data for 
performance, focusing solely on the latter can result in a mislead- 
ing evaluation. For example, by forcing applications to operate at 
their lowest fidelity levels at all times, a system could ensure better 
performance than a competing system that strives to support higher 
fidelity levels when possible. Yet, this degenerate approach vio- 
lates our intuitive notion of what constitutes a good system. Hence, 
the evaluation of an adaptive system must take into account both 
fidelity and performance. 

2.3 Concurrency 

The ability to execute multiple independent applications concur- 
rently on a mobile client is vital. Although this ability is taken for 
granted on desktop operating systems, there continues to be skep- 
ticism about its value in mobile clients. This skepticism is fueled 
by the popularity of devices such as PDAs [1] and pocket organiz- 
ers [39], which execute only one application at a time. 

While such specialized mobile devices fill an important niche, 
we are convinced that many mobile users will find it valuable to run 
background applications in addition to the foreground application 
that dominates their attention. For example, an information filter- 
ing application may run in the background monitoring data such 
as stock prices or enemy movements, and alert the user as appro- 
priate. As another example, an application used in emergency re- 
sponse situations may monitor physical location and motion, and 
prefetch damage-assessment information for the areas to be tra- 
versed shortly. 

To effectively support concurrent applications, one must control 
their use of limited resources. In other words, there needs to be 
centralized monitoring and coordinated resource management on 
a mobile client. Operating systems, which have historically per- 
formed this role for CPU cycles and memory, must now manage a 
broader range of resources such as network bandwidth, disk cache 
space and battery power. 

The need to coordinate resource management across applications 
mutes the effectiveness of many current approaches to mobile com- 
puting. For example, commercial applications such as Eudora [29] 
provide vertically integrated support for mobility, where each appli- 
cation assumes that it has full use of available network bandwidth. 



Even a more sophisticated toolkit approach such as Rover [ 1 3] only 
pays minimal attention to resource coordination. 

2.4 Agility 

Sound adaptation decisions require accurate and timely knowledge 
of resource availability. Ideally, a mobile client should always have 
perfect knowledge of current resource levels. In other words, there 
should be no time lag between a change in resource availability 
and its detection. Further, if this change is sufficient to warrant 
modification of client behavior, that too should be accomplished 
without delay. 

Of course, no physical system can meet this ideal. The best we 
can hope for is to build close approximations through good design 
and engineering. Thus, a key property of an adaptive system is the 
speed and accuracy with which it detects and responds to changes 
in resource availability. We call this property the agility of the sys- 
tem. When changes are large and erratic, only a highly agile system 
can function effectively. In more stable environments, less agile 
systems may suffice. Agility is thus the property of a mobile sys- 
tem that determines the most turbulent environment in which it can 
function acceptably. 

Agility is a complex property with many components. One 
source of complexity is differing sensitivity to different resources. 
For example, a system may be much more sensitive to changes in 
network bandwidth than to changes in battery power level. An- 
other source of complexity is differing origins of changes in re- 
source availability. The change may be caused by variation in the 
supply of a resource due to mobility, or by changed demand for it 
by concurrent applications. Since different mechanisms may be in- 
volved in detecting these two different types of changes, it may be 
necessary to distinguish these components of agility. 

2.5 Minimalism 

Rather than using a clean-sheet approach to designing Odyssey, we 
decided to extend an existing system. We chose NetBSD, a vari- 
ant of the 4.4 BSD Unix operating system [23], as the starting 
point. NetBSD source code is publicly available without encum- 
brance, thus allowing free distribution of derivatives. The popular- 
ity of NetBSD also offers the possibility of attracting a substantial 
Odyssey user community. 

We avoided changes to the NetBSD API and internal structure 
unless essential, and made the few necessary changes consistent 
with NetBSD idiom. Thus, Odyssey should be viewed as an ex- 
ercise in minimalism: it represents the smallest set of interface and 
code extensions we believe necessary for agile adaptation in mobile 
environments. 

3 Application-Aware Adaptation 
3.1 Model of Adaptation 

Odyssey's approach to adaptation is best characterized as 
application-aware adaptation. The essence of this model is a col- 
laborative partnership between the system and individual applica- 
tions. The system monitors resource levels, notifies applications of 
relevant changes, and enforces resource allocation decisions. Each 
application independently decides how best to adapt when notified. 

This division of responsibility directly addresses the issues of ap- 
plication diversity and concurrency. Diversity is accommodated by 
allowing applications to determine the mapping of resource levels 
to fidelity levels. Concurrency is supported by allowing the sys- 
tem to retain control of resource monitoring and arbitration. The 
challenge is to design a system that can support this separation of 
concerns without compromising agility. 
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Figure 1 : Models of Adaptation 

Figure 1 places application-aware adaptation in context, span- 
ning the range between two extremes. At one extreme, adaptation 
is entirely the responsibility of individual applications. This laissez- 
faire approach, used by commercial software packages such as Eu- 
dora, avoids the need for system support. But, as discussed in Sec- 
tion 2.3, it fails to address the issue of application concurrency. At 
the other extreme, application-transparent adaptation, the system 
bears full responsibility for both adaptation and resource manage- 
ment. This approach, exemplified by Coda, is especially attractive 
for legacy applications because they can run unmodified. Applica- 
tion concurrency is well supported, but application diversity is not, 
since control of fidelity is entirely in the hands of the system. 

3.2 Realizing the Model 

The obvious approach to implementing application-aware adapta- 
tion would be to directly reflect its separation of concerns in the 
Odyssey architecture. In such an architecture, system code would 
treat data generically; individual applications would be entirely re- 
sponsible for differential handling of data types. 

Unfortunately, the wide disparity in the physical and logical 
properties of various data types requires that some form of type- 
awareness be incorporated into the system for efficient resource us- 
age. For example, the size distribution and consistency require- 
ments of data from an NFS server differ substantially from those of 
relational database records. Image data may be highly compressible 
using one algorithm but not another. Video data can be efficiently 
shipped using a streaming protocol that drops rather than retrans- 
mits lost data; in contrast, only reliable transmissions are accept- 
able for file or database updates. It is impossible to optimize for 
such differences without some system-level knowledge of type. 

These considerations lead to a more sophisticated architecture in 
which Odyssey has two responsibilities. It must be aware of shared 
access to remote data by concurrent applications so that it can prop- 
erly manage resources. At the same time, it must have type-specific 
knowledge to allow effective resource management actions. Such 
knowledge is necessary, for example, to estimate the relative costs 
and benefits of compressing a cached item versus flushing it and 
refetching it later 

Odyssey incorporates type-awareness via specialized code com- 
ponents called wardens. A warden encapsulates the system- level 
support at a client necessary to effectively manage a data type. To 
fully support a new data type, an appropriate warden has to be writ- 
ten and incorporated into Odyssey at each client. The wardens are 
subordinate to a type-independent component called the viceroy, 
which is responsible for centralized resource management. 

The collaborative relationship envisioned in application-aware 
adaptation is thus realized in two parts. The first, between the 
viceroy and its wardens, is data-centric: it defines the fidelity lev- 
els for each data type and factors them into resource management. 
The second, between applications and Odyssey, is action-centric. 
it provides applications with control over the selection of fidelity 
levels supported by the wardens. 



4 Design and Implementation 

An implementation of Odyssey must enable an application to 

• operate on Odyssey objects, 

• express resource expectations, 

• be notified when expectations are no longer met, and 

• respond by changing fidelity. 

The Odyssey mechanisms supporting each of these requirements 
are described in the following sections. 

4.1 Operating on Odyssey Objects 

Consistent with our goal of minimalism, we have built upon 
NetBSD file system calls rather than defining a completely new in- 
terface. Thus, Odyssey is integrated into NetBSD as a new VFS file 
system [19]. In addition, we have found it necessary to add a few 
new system calls. 

As shown in Figure 2, we have implemented the viceroy and war- 
dens in user space rather than in the kernel. Operations on Odyssey 
objects are redirected to the viceroy by a small in-kernel interceptor 
module. All other system calls are handled directly by NetBSD. 
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Figure 2: Odyssey Client Architecture 

Wardens are statically linked with the viceroy, and the ensemble 
executes in a single address space with user-level threads. Com- 
munication between the viceroy and wardens is through procedure 
calls and shared data structures. The wardens are entirely respon- 
sible for communicating with servers and caching data from them 
when appropriate — applications never contact servers directly. 

Our implementation of Odyssey outside the kernel is consistent 
with the philosophy of modern operating system designs such as 
Exokernel [6] and SPIN [3]. Since extensibility is the motivation 
for such systems, their use in the context of Odyssey should result 
in improved agility and easier installation of new wardens. 

Integrating Odyssey with the file system yields several key ad- 
vantages. It gives us a well-understood framework for integration 
as well as useful infrastructure to simplify implementation. Since 
file operations are performed on Odyssey objects by the appropriate 
warden, their semantics can be customized to provide a modicum 
of type-awareness without new system calls. 

At the same time, our approach imposes certain limitations. 
Some data types do not naturally fit either the naming or access 
methods provided by the file system. Further, there are no standard 
file operations corresponding to fidelity changes. For naming, we 
incorporate extensions similar in spirit to virtual directories [9]. For 
access methods and fidelity changes, we rely on a general-purpose 
mechanism described in Section 4.4. 

As Odyssey matures, we may discover that further improve- 
ments in functionality or agility are impossible unless we move the 
viceroy and wardens into the kernel. Until there is compelling evi- 
dence of this, however, we plan to retain the current architecture. 
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(c) Generic Resources in Odyssey 

handler(in request-id, in resource-id, in resource- level)"] 
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tsop(in path, in opcode, in insize, in inbuf, 
inout outsize, out outbuf) 



(e) Type-Specific Operations 

This figure shows Odyssey's extensions to the NetBSD program- 
ming interface. Note that the request and tsop calls have vari- 
ants that identify Odyssey objects by file descriptors rather than 
pathnames. 

Figure 3: Odyssey API 

4.2 Expressing Resource Expectations 

Applications communicate resource expectations to Odyssey using 
the request system call shown in Figure 3(a). The call takes a 
resource descriptor identifying a resource and specifying a window 
of tolerance on its availability. This call expresses the application's 
desire to be told if the availability of the resource strays outside the 
window. 

If, at the time of the request, the availability of the resource 
is within the window of tolerance, the viceroy registers the request 
and returns a unique identifier for it. This identifier can be used by 
the viceroy in notifying the application that the resource has left the 
requested bounds, or by the application in a future cancel system 
call to discard the registered request. 

If the resource is currently outside the bounds of the tolerance 
window, an error code and the current available resource level are 
returned. The application is then expected to try again, with a new 
window of tolerance corresponding to a new fidelity level. 

The fields of a resource descriptor are shown in Figure 3(b). Each 
resource is named by a unique resource identifier. Figure 3(c) lists 
the generic resources we plan to manage in Odyssey. At present the 
prototype only manages the most critical resource in mobile com- 
puting: network bandwidth. The window of tolerance is indicated 
by lower and upper bounds. A resource descriptor also specifies the 
name of a procedure that will be called to notify the application that 
the resource has left the window. 



4.3 Notifying Applications 

When the viceroy discovers that the availability of a resource has 
strayed outside a registered window of tolerance, it generates an 
upcall to the corresponding application. The application adjusts 
its fidelity according to its individual policy. It then issues another 
request call to register a revised window of tolerance appropriate 
to the new fidelity. 

An upcall handler is invoked with three parameters, as shown in 
Figure 3(d). The first parameter identifies the request operation 
on whose behalf the upcall is being delivered. The second param- 
eter identifies the resource whose availability has changed, and the 
third parameter gives the new availability. 

Upcalls closely resemble Unix signals, but offer improved func- 
tionality. Like signals, upcalls can be sent to one or more processes, 
can be blocked or ignored, and have similar inheritance semantics 
on process fork. Unlike signals, upcalls offer exactly-once, in-order 
semantics for each receiver of a particular upcall. Further, upcalls 
allow parameters to be passed to target processes and results to be 
returned. 

4.4 Changing Fidelity 

Requests for fidelity changes do not map well to the NetBSD file 
system interface. Further, many data types have natural access 
methods that are not well supported by the untyped byte stream 
model. To address these shortcomings, we have included a general- 
purpose escape mechanism called tsop, or type-specific operation, 
shown in Figure 3(e). The arguments to tsop specify an Odyssey 
object and the opcode of a type-specific operation to be performed 
on it. Input and output parameters are specified as unstructured 
memory buffers, in the spirit of the ioctl system call. 

5 Example Applications 

To explore Odyssey's ability to support application diversity, we 
modified three very different applications to run on it. The first 
two applications are drawn from the domain of mobile information 
access: a video player whose source code we have access to, and 
a Web browser whose source code is not publicly available. The 
third application, a speech recognizer, was chosen to explore the 
effectiveness of Odyssey outside its original target domain. 

Each application requires a different strategy for integration into 
Odyssey, and each has distinct notions of fidelity. Collectively, 
these applications serve as a vehicle to explore the generality and 
performance characteristics of Odyssey. 

5.1 Video Player 

Our support for video is based on xanim, a public-domain software 
package that can generate video animation from data stored in vari- 
ous formats in a local file. As shown in Figure 4, we split its mono- 
lithic implementation into a client and server, and wrote a warden 
to satisfy client requests and fetch data from the server. 
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Figure 4: Video Player in Odyssey 



Each movie is stored in multiple tracks at the server, one track 
per fidelity level. We have incorporated three levels of fidelity for 
Quicktime [11] video data: JPEG-compressed [42] color frames at 
qualities 99 and 50, and black-and-white frames. Storing all three 
tracks incurs only modest overhead, typically about 60% more than 
storing just the highest fidelity track. 

The warden supports two tsops: to read a movie's meta-data, 
and to get a particular frame from a specified track. The warden 
performs read-ahead of frames to lower latency. 

When the player opens a movie, it calculates the bandwidth re- 
quirements of each track from the movie meta-data. The player 
begins the movie at highest possible quality, and registers the cor- 
responding window of tolerance with Odyssey. When it is notified 
of a significant change in bandwidth, the player determines a new 
fidelity level and switches to the corresponding track. If the player 
switches from a low fidelity track to a higher one, the warden dis- 
cards the prefetched low-quality frames. 

5.2 Web Browser 

Netscape Navigator, or simply Netscape, is a widely-used tool for 
accessing the World-Wide Web. It is an especially interesting ap- 
plication for Odyssey because we do not have access to its source 
code. Since we cannot directly modify Netscape to take advantage 
of Odyssey, we exploit its proxy facility as shown in Figure 5. 



5.3 Speech Recognizer 

Speech recognition offers considerable potential as well as chal- 
lenge for mobile computing. It is especially useful when mobile 
because it leaves the user's hands and eyes free for other activi- 
ties such as driving [34]. However, the resource requirements for 
high-accuracy speech recognition are substantial, especially when 
mobile, since background noise is often high. Adding higher-level 
semantic processing, such as language translation, leads to even 
greater demands on computing resources. This combination of op- 
portunity and challenge led us to implement speech recognition as 
an Odyssey application, even though it falls outside our primary 
domain of mobile information access. 
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Figure 5: Extending Netscape for Odyssey 

All of Netscape's requests are redirected to a client module called 
the cellophane. Together, Netscape and the cellophane constitute a 
single application from the viewpoint of Odyssey. The cellophane 
makes use of the Odyssey API and selects fidelity levels. Netscape 
passively benefits from the adaptation initiated by the cellophane. 

The cellophane transforms HTTP requests from Netscape into 
file operations on Odyssey Web objects. The Web warden forwards 
these requests via the client's mobile network connection to a dis- 
tillation server. The latter provides multiple levels of fidelity for 
images along the lines suggested by Fox et al [7]. Since images 
tend to be large and constitute a substantial fraction of HTTP traffic, 
focusing on them has a high payoff. At the highest fidelity, images 
are uncompressed. Progressively lower levels correspond to JPEG- 
compressed images of decreasing quality. The warden provides a 
tsop to set the fidelity level. 

The distillation server fetches requested objects from the appro- 
priate Web server, distills them to the requested fidelity level, and 
sends the results to the warden. The data is then passed to Netscape 
via the cellophane. These steps are completely transparent to both 
Netscape and the Web server; each perceives normal Web access. 

Netscape exemplifies the unfortunate reality that source code is 
not publicly available for a growing number of important applica- 
tions. Code interpositioning, the approach described above, repre- 
sents only one way for such shrink-wrapped applications to benefit 
from Odyssey. Other possibilities include static binary rewriting of 
executables and dynamic modification of system calls. 



Figure 6: Speech Recognition in Odyssey 



Figure 6 illustrates our support for speech recognition in 
Odyssey. The starting point for this implementation is a speech 
recognition system called Janus [41], whose source code is avail- 
able to us. We have split this system into a client and server, and 
constructed a speech warden. The server accepts two forms of in- 
put: a raw utterance, or an utterance that has already been processed 
by the first of several phases of Janus. This pre-processing yields a 
compression ratio of approximately 5:1 at modest CPU cost. 

The speech front-end captures a raw speech utterance and then 
writes it to an object in the Odyssey namespace. The warden, using 
the current bandwidth estimate, decides whether it is faster to per- 
form the first pass of the recognition on the local, slower CPU, or 
to ship the larger, raw utterance to the server. In the extreme case 
of disconnection, the local Janus is capable of recognizing the ut- 
terance, but at a severe CPU and memory cost. When the utterance 
is recognized, the resulting text is made available to the front-end 
through a read operation. We are currently refining our imple- 
mentation to support multiple levels of recognition fidelity. 

6 Evaluation 

Three central questions drove our evaluation of Odyssey: 

• How agile is Odyssey in the face of changing network band- 
width? 

• How beneficial is it for applications to exploit the dynamic 
adaptation made possible by Odyssey? 

• How important is centralized resource management for con- 
current applications? 

In posing these questions, two secondary questions come to light. 
First, how should the concept of agility be quantified? Second, 
what experimental methodology should we use to obtain agility 
metrics? We address these secondary questions first, in Section 6. 1, 
and present our answers to the primary questions in Section 6.2. 



6.1 Evaluation Strategy 
6.1.1 Agility Metrics 

Our approach to quantifying agility draws upon well-established 
principles for measuring dynamic response from the field of control 
systems [4, 30]. The accepted practice in that field is to characterize 
the adaptive ability of a system with respect to a particular output in 
terms of its responses to a set of input reference waveforms. Each 
reference waveform is conceptually simple, yet greatly stresses the 
adaptive ability of the system by varying the input in some sharp 
and substantial manner. 



(a) Step-Up (b) Step-Down 



(c) Impulse-Up (d) Impulse-Down 

The Step-Up and Step-Down waveforms arc each 60 seconds long, 
with a single, abrupt transition at the midpoint. The Impulsc-Up and 
Impulse-Down waveforms are approximations to the ideal impulse, 
which is a spike of infinitesimal width and infinite height. We ap- 
proximate the ideal with two-second wide excursions in the middle 
of a 60-sccond period. Our choice of parameters for these wave- 
forms is based on our estimate of the basic network time constants of 
typical distributed systems today: 30 seconds should be long enough 
for a system to reach steady state after a bandwidth perturbation; a 
2 second perturbation is large enough to be detectable by a sensitive 
system, yet small enough to be missed by an insensitive one. 

Figure 7: Reference Waveforms for Agility Experiments 

Figure 7 illustrates the reference waveforms used in our evalu- 
ation. Although these waveforms are idealized, approximations to 
them can occur in practice. The step waveforms can arise in over- 
lay networks, where a mobile client may seamlessly switch between 
different network interfaces. Further, virtual radios such as Spec- 
trumWare [37] may allow sharp bandwidth degradation. Impulse 
waveforms can arise as a result of frequent transitions in either of 
these situations, or in the presence of bursty background traffic. 
6.1.2 Experimental Methodology 

Generating Discontinuous Waveforms To subject Odyssey and 
its applications to these reference waveforms, we need to generate 
sharp discontinuities in network bandwidth. Accomplishing this 
in a repeatable and reliable manner is extremely difficult on any 
real network or combination of networks. We solve this problem 
through a technique called trace modulation [26, 33]. 

Trace modulation performs application-transparent emulation of 
a slower target network over a faster, wired LAN. It is implemented 
in two parts: a layer inserted in the protocol stack between the trans- 
port and network layers, and a user-level daemon. The added layer 
delays all traffic into and out of the modified host according to a 
simple linear model combining latency and bandwidth-induced de- 
lays. The daemon reads a list of model parameters, called a re- 
play trace, from a file and feeds it to the delay layer. We have 
created synthetic replay traces to obtain the bandwidth variations 
corresponding to the reference waveforms. 

Interpreting Results Since Odyssey applications trade fidelity 
for performance, interpreting the results of experiments requires 
some care. In comparing two strategies, one is strictly better than 
the other if it provides better fidelity with comparable performance, 
or better performance with comparable fidelity. In other cases, the 
comparison must take into account the application's goals. 



These comparisons are clearly dependent on the choice of fidelity 
metrics. However, since only relative comparisons are made within 
a single application, the only requirement on fidelity is that it be 
strictly increasing as the quality of presented data increases. 

6.1.3 Experimental Conditions 

All of our experiments used identical hardware and software con- 
figurations: a single 90 MHz Pentium client with 32 MB of mem- 
ory, and a collection of 200 MHz Pentium Pro servers with 64 MB 
of memory. These machines were running a NetBSD 1 ,2 kernel 
customized to include Odyssey and trace modulation extensions; 
modulation was performed at the client. 

The bandwidth levels encoded in our modulation traces were 
chosen with two constraints in mind. First, they must be reasonably 
achieved on current wireless hardware. Second, they must provide 
for interesting tradeoffs when running our sample applications. We 
chose 120 KB/s (kilobytes per second) and 40 KB/s for the high 
and low bandwidth levels. The protocol round trip time measured 
on our setup was 21 ms for both bandwidths. 

6.2 Experimental Results 
6,2.1 How Agile is Odyssey? 

In order to allow applications to make intelligent trade-offs between 
performance and quality, Odyssey must track changes in both the 
supply of and demand for network bandwidth. Because Odyssey 
may often be used in weakly-connected environments, we rely on 
purely passive observations rather than an active approach such as 
that suggested by Keshav [17]. These observations are logged by 
our user-level RPC mechanism [25] which is implemented on UDP. 
This mechanism combines a conventional RPC protocol for small 
exchanges with a sliding-window, selective-acknowledgement pro- 
tocol for bulk data transfer. Each distinct endpoint has its own 
log, and observations for different endpoints are recorded indepen- 
dently. 

Log entries are of two kinds: round trip entries that are recorded 
for small exchanges, and throughput entries that arise from bulk 
transfers. Each round trip entry records the time, T rt t, to send a 
request to a server and receive a response, less server computation 
time. Each throughput entry records T w i n , which is either the time 
for a receiver to request and receive a window's worth, D, of data, 
or for a sender to transmit that data and receive an acknowledge- 
ment. Round trip and throughput estimates are both smoothed by 
the viceroy using the following equation: 

new = a (measured) + (1 — a) (old) (1) 

Our implementation uses an a of 0.75 for round trip time, and 0.875 
for throughput. 

To obtain a bandwidth estimate, we observe that the transmis- 
sion time for D bytes is T w { n minus the time for transmitting the 
acknowledgement or the time to transmit the request. Assuming 
symmetrical data rates, both of these are T r tt/2. This yields the 
following expression for bandwidth: 



Noise in round trip estimates can severely impact bandwidth es- 
timates; to discount anomalous increases in round trip time, we cap 
the percentage rise possible at each estimate. This has the effect 
of erring on the side of caution and underestimating bandwidth in 
certain situations, but eliminates anomalies introduced by our user- 
level implementation. 

The viceroy collects information from all logs to estimate the to- 
tal bandwidth available to the client. It then estimates the fraction 



of this bandwidth likely to be available to each connection. A con- 
nection estimate is composed of two parts: a competed-for part pro- 
portional to recent use, and a fair-share part reflecting an expected 
lower bound. 

Varying Supply To measure agility with respect to bandwidth 
supply, we ran a synthetic Odyssey application, bitstream, that con- 
sumed data as fast as possible through a streaming warden over a 
single connection from a server. During data transfer, we varied 
network bandwidth in accordance with the reference waveforms of 
Figure 7. To ensure that the system was in steady state, we primed 
it for thirty seconds prior to observation. The bandwidth estimated 
by Odyssey for each waveform is shown in Figure 8. 

Figure 8(a) shows that Odyssey demonstrates excellent agility 
on the Step-Up waveform by detecting its bandwidth increase al- 
most instantaneously. The second graph, Figure 8(b), shows that 
agility on the Step-Down waveform is not quite as good as on Step- 
Up. The settling time for this waveform — the time required to 
reach and stay within the nominal bandwidth range — is 2.0 sec- 
onds. The slower downward transition is caused by the fact that 
we generate a throughput estimate only at the end of a window of 
data. If bandwidth falls abruptly while a large window of data is 
being transmitted, the drop is not recorded until the last packet of 
the window arrives. 

Figures 8(c) and 8(d) show agility for the Impulse-Up and 
Impulse-Down waveforms. The leading edge of the upward im- 
pulse is accurately traced, but the trailing edge has a noticeable set- 
tling time. The downward impulse is too short for estimation to 
settle accurately, and there is again a noticeable settling time on the 
trailing edge of the impulse. 

Varying Demand We next examine agility with respect to band- 
width demand. We began these experiments with a single bitstream 
application running on a client. As before, we primed the system for 
thirty seconds to ensure that it was in steady state before beginning 
observation. After thirty seconds of observation, we introduced a 
second, identical bitstream client. To study sensitivity of the re- 
sults to offered load, we repeated the experiments with each appli- 
cation attempting to consume 10%, 45%, and 100% of the nominal 
throughput. All experiments were conducted at the higher of our 
two modulated bandwidths. 

Figures 9(a)-9(c) show the viceroy's estimation of the bandwidth 
available to the two competing streams. In all experiments, the sec- 
ond stream causes some transient effects when it is started. This 
transient is much more pronounced in the two higher-load experi- 
ments; in the full-utilization case it takes almost 5 seconds to settle 
back to the nominal value. 

At low utilization, the second stream reaches its nominal value 
almost immediately; in the other two cases, this takes longer. 
Higher rates of consumption by the first stream give it more weight 
compared to the startup of the second stream. Hence, the first 
stream is given more of the competed-for bandwidth until the sec- 
ond stream has established itself. 

6.2.2 How Beneficial is Adaptation? 

We next compare the performance and fidelity of adaptive applica- 
tions using Odyssey with versions of these applications using static 
policies. In this comparison, we represent fidelity as a number be- 
tween zero and one that indicates, in an application-specific man- 
ner, the quality of data delivered. 

In our experiments, each application executed the same workload 
using an adaptive strategy as well as one fixed strategy per fidelity 
level. Each execution was repeated for all the reference waveforms. 
As before, we primed the experiment with a thirty second period of 
constant bandwidth to eliminate startup transients. 
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This figure shows the agility of bandwidth estimation in the face of 
varying supply. Each graph merges the results from five trials, and 
each bandwidth observation is represented by a single dot on the 
graph. The dashed lines represent the theoretical bandwidth of the 
emulated network, as specified by the synthetic traces used for emu- 
lation. The dotted lines arc the measured, instantaneous throughputs 
obtained using a large bulk transfer between client and server. Ide- 
ally, all samples would lie between the dashed and dotted lines. 

Figure 8: Supply Estimation Agility 
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This figure shows the agility of bandwidth estimation; note that we 
measure availability, not consumption. The upper curve is the total 
estimated bandwidth; the lower is the bandwidth available to the sec- 
ond stream, which starts after 30 seconds. The pairs of straight lines 
show the nominal ranges for each curve; a perfectly agile system 
would always show the upper and lower curves within their respec- 
tive pairs. Each graph depicts the results of five trials. The solid lines 
show averages, and gray regions show the spread between observed 
maximum and minimum values. 

Figure 9: Demand Estimation Agility 



Video Player We compare the adaptive behavior of the Odyssey 
video player to three fixed policies: always JPEG(99), always 
JPEG(50), and always black-and-white. The higher bandwidth 
is sufficient to fetch JPEG(99) frames. At the low bandwidth, 
JPEG(50) frames can be fetched without loss. All movie tracks 
are encoded at ten frames per second, with 600 frames to display 
during each trial. 

JPEG(99) frames are assigned a fidelity of 1 .0, JPEG(50) frames 
have a fidelity of 0.5, and black-and-white frames a fidelity of 0.01 . 
The fidelity for a single execution of xanim is the average fidelity 
of frames displayed. Thus a movie with half of its frames displayed 
from each of the two best tracks would have a fidelity of 0.75. The 
performance metric is frames dropped. Xanim *s adaptation goal is 
to play the highest quality possible without dropping frames. Other 
applications might choose, instead, to preserve frame quality but 
reduce the frame rate. 



Figure 10 summarizes the results of the xanim benchmark. 
In both Step waveforms, roughly half the frames displayed by 
Odyssey are JPEG(50) frames, and the other half JPEG(99) frames. 
For Impulse-Up, Odyssey shows only JPEG(50) frames, and for 
Impulse-Down almost all JPEG(99) frames. Thus, the adaptive 
xanim nearly always displays the optimal quality frame. 

For all waveforms other than Impulse-Up, Odyssey achieves a 
much better fidelity than JPEG(50), with only a modest increase 
in dropped frames. For all waveforms other than Impulse-Down, 
Odyssey drops many fewer frames than the JPEG(99) strategy by 
reverting to JPEG(50) frames at low bandwidth. For Impulse- 
Down, Odyssey is indistinguishable from the JPEG(99) strategy. 

In the adaptive strategy, dropped frames occur primarily during 
the downward bandwidth transitions. It takes at least one data trans- 
fer for Odyssey to notice the drop in bandwidth, and that transfer is 
fetching high-quality frames, which are destined to be late. 

Web Browser For the Web browser experiments, we repeatedly 
fetched a 22KB image as fast as possible. To preserve experimental 
control, the image was stored on a Web server on the test network, 
with a distillation server interposed between the client and the Web 
server. The cellophane could choose one of four levels of fidelity: 
original quality or JPEG compression at quality levels 50, 25, or 
5. The fidelity of each of these levels is 1.0, 0.5, 0.25, and 0.05 
respectively. The fidelity for an experiment is the average fidelity 
of all images fetched in that experiment. 

The performance metric is the average time to fetch and display 
an image during an execution. For the baseline against which to 
compare, we executed the trace on an unmodified, private Ethernet. 
Our Web client's adaptation goal is to display the best quality image 
that can be fetched within twice the Ethernet time, in this case 0.4 
seconds. With this goal, full-quality images can be fetched at the 
high bandwidth. At low bandwidth JPEG(50) is the best possible. 

Figure 1 1 summarizes the results of the Web benchmark. The 
static strategy of fetching full-quality images only meets our per- 
formance goals in the Impulse-Down case. This is not surprising, 
as most of that trace provides sufficient bandwidth for full-quality 
images. In contrast, Odyssey meets our performance goal in all 
cases, and does so at better quality than any of the sufficiently fast 
static strategies. In the Impulse-Up case, Odyssey is fooled into 
fetching better quality images for a brief period by the impulse's 
transient increase in bandwidth. 

Speech Recognizer For the speech experiments, we recognized a 
single, short phrase, repeating the recognition as quickly as possi- 
ble. Since the quality of recognition does not vary, the only inter- 
esting metric is the speed with which recognitions take place. Fig- 
ure 12 gives the recognition times for the three possible strategies: 
always hybrid, always remote, and adaptive. 

At the bandwidths in our reference traces, hybrid translation is 
always the correct strategy when speech is the sole application. As 
Figure 12 shows, Odyssey duplicates the always-hybrid strategy. 
We have confirmed, through experiments not reported here, that at 
higher bandwidths an adaptive strategy has benefits. 

6.2.3 How Important is Centralized Resource Management? 

Finally we examine the usefulness of Odyssey's centralized re- 
source management. We do this by comparing Odyssey with two 
forms of uncoordinated resource management, with all three appli- 
cations concurrently running on the much longer synthetic wave- 
form shown in Figure 13. 

As a basis of comparison we modified the viceroy to support 
laissez-faire resource management; rather than combining infor- 
mation from all logs as in Section 6.2.1, each log is examined in 
isolation. This reflects what applications would discover on their 
own: information is less accurate than that globally obtained but 
with similar delays in discovery. 
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This tabic gives the fidelity and number of frames dropped by xanim under various strategics for each of the four reference waveforms. Note 
that larger fidelity values represent better quality, while fewer dropped frames indicates better performance. Each observation is the mean of 
five trials, with standard deviations given in parentheses. Notice that Odyssey achieves fidelity as good as or better than the JPEG(50) strategy 
in all cases, but performs as well or better than JPEG(99) within experimental error. 

Figure 10: Video Player Performance and Fidelity 
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This table gives the fidelity and average time for Netscape to fetch and display our test image under various strategics for each of the four refer- 
ence waveforms. Note that larger fidelity numbers represent better quality, while smaller times indicate better performance. Each observation 
is the mean of five trials; standard deviations are given in parentheses. Notice that Odyssey achieves a better fidelity than JPEG(50) in all cases 
and, unlike the full-quality strategy, meets our performance goal within experimental error for all cases. 



Figure 1 1 : Web Browser Performance and Fidelity 



One could also imagine the networking layer of an operat- 
ing system immediately notifying applications when switching be- 
tween networking technologies. We have implemented this strat- 
egy, which we call blind-optimism ^ by passing the theoretical band- 
width to the viceroy at each transition via an upcall. The viceroy 
then notifies any interested applications. This information is less 
accurate because it does not reflect the impact of any other applica- 
tions, but is delivered without the delay of bandwidth discovery. 

Figure 14 presents the results of this experiment. The fidelity and 
performance metrics as well as the application goals for this exper- 
iment are the same as in Section 6.2.2. The message of Figure 14 is 
that Odyssey's centralized resource estimation provides significant 
benefits over both laissez-faire and blind-optimism. By correctly 
accounting for bandwidth competition, the Odyssey Web browser 
and video player fetch data at lower fidelity, thus enabling all appli- 
cations to come much closer to their performance goals. Odyssey 
drops a factor of 2 to 5 fewer frames than the other strategies, and 
Web pages are loaded and displayed roughly twice as fast. The re- 
sulting decrease in network utilization improves speech recognition 
time as well. 

7 Related Work 

To the best of our knowledge, Odyssey is the first system to simul- 
taneously address the problems of adaptation for mobility, applica- 
tion diversity, and application concurrency. It is the first effort to 
propose and implement an architecture for application-aware adap- 
tation that pays careful attention to the needs of mobile computing. 
The identification of agility as a key attribute for mobile systems, 
and the first approach to evaluating it, have both occurred in the 
context of Odyssey. 

At the same time, Odyssey has benefited considerably from much 





Recognition Time (sec.) 


Waveform 


Always 
Hybrid 


Always 
Remote 


Odyssey 


Step-Up 
Step-Down 
Impulse-Up 
Impulse-Down 


0.80 (O.oo) 
0.80 (0.00) 
0.85 (O.oo) 
0.76 (O.oo) 


0.91 (O.oo) 
0.90 (o.oo) 

1.11 (0.00) 

0.77 (O.oo) 


0.80 (o.oo) 
0.80 (O.oo) 
0.85 (o.oo) 
0.76 (o.oi) 



This table gives the average time, in seconds, for a recognition by 
the speech application for each of the two static strategics as well as 
the adaptive strategy for each of the four reference waveforms. Each 
observation is the mean of five trials. Standard deviations are shown 
in parentheses. Note that Odyssey correctly reproduces the always- 
hybrid case, which is optimal at our reference bandwidth levels. 

Figure 12: Speech Recognizer Performance 
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This 15-minutc synthetic trace models the bandwidth variation seen 
by a user walking through a hypothetical urban setting. Each number 
indicates the time duration of the corresponding segment in minutes. 
The high and low bandwidths arc as indicated in Section 6.1.3. The 
user begins well-connected but soon enters a region of intermittent 
quality. She then enters the radio shadow caused by a large building, 
and finally returns to good connectivity. 

Figure 13: Bandwidth Variation in Urban Scenario 
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This table demonstrates the benefit of Odyssey's centralized resource management by comparing it to two implementations of uncoordinated 
resource management. The fidelity and performance metrics for this experiment arc the same as in Figures 10-12. Notice that by degrading 
the fidelity of fetched video and web data, Odyssey comes closer to each application's performance goals by factors of 2-5. Such a trade-off is 
made possible by Odyssey's more accurate estimation of bandwidth available to each application. Each observation in this table is the mean of 
five trials, with standard deviations given in parentheses. 



Figure 14: Performance and Fidelity of Concurrent Applications 



previous work. A substantial debt is owed to Coda, which first 
demonstrated that client resources could be effectively used to insu- 
late users and applications from the vagaries of mobile information 
access, The strategy of trading lowered consistency for improved 
availability was shown to be effective and usable by Coda and re- 
lated systems such as Ficus and Bayou. It was the recognition that 
consistency represented a particular dimension of the broader con- 
cept of fidelity that led to the design of Odyssey. Many aspects of 
the Odyssey prototype, such as its implementation in user space and 
its use of a log-based mechanism for monitoring network quality, 
were based on positive experience with similar strategies in Coda. 

Many systems together served as a backdrop to our thinking on 
fidelity: the Rover toolkit; mobile Web software such as Mobi- 
saic [40] and W4 [2]; software embodying concepts such as dy- 
namic documents [14] and distillation [7]; commercial email pack- 
ages such as Eudora; and numerous PDAs and pocket organiz- 
ers. Examination of these systems also helped us identify an es- 
sential missing ingredient in all of their designs: effective man- 
agement of scarce resources across multiple applications. These 
systems, in conjunction with Coda, helped us formulate our tax- 
onomy of adaptation strategies — laissez-faire, application-aware, 
and application-transparent. 

The issues of resource reservation and guarantees lie at the heart 
of real-time systems [24], and have become important in high per- 
formance networking [8]. These communities have recently applied 
reservation techniques, with two changes, to mobile clients [20, 27]. 
First, rather than reserving a particular quantity of a resource, they 
reserve a range; the underlying system transparently adapts within 
the range. Second, if the range is exceeded or the client moves, a 
renegotiation involving some or all of the end-to-end path is initi- 
ated. 

In contrast to these systems, Odyssey abandons the reservation 
model entirely; either the reserved bounds would be so wide as to 
degenerate to application-transparent adaptation, or costly renegoti- 
ations on behalf of a mobile host would be too frequent. Framed as 
an end-to-end consideration, ultimate responsibility for coping with 
changes in resource levels resides with applications. Odyssey's role 
is only to improve efficiency, agility and fairness by insulating ap- 
plications from insignificant variations in resource levels, and by 
providing a focal point for resource monitoring and allocation. 

Recent adaptive systems, such as McCanne's RLM [22] and In- 
ouye's video player [12], employ feedback-driven adaptation rather 
than Odyssey's measurement-based approach. Such systems scale 
back quality, and hence resource consumption, when application 
performance is poor, and they attempt to discover additional re- 
sources by optimistically scaling up usage. Using application- 
specific feedback relieves such systems of the need to calibrate to 
individual resources, but this feedback is per-appli cation. As this 



paper has shown, this kind of laissez-faire approach does not pro- 
vide for application concurrency, even though it works well for in- 
dividual applications. Further, attempts to increase resource usage 
amount to active rather than passive resource monitoring, a ques- 
tionable strategy when bandwidth is scarce. 

Finally, the installation of pieces of code at low levels of the sys- 
tem to encapsulate specialized knowledge about different data types 
is a common practice in databases [10]. The primary purpose of 
such code is to improve disk management. The use of wardens in 
Odyssey resembles this practice, but differs in that wardens support 
multiple fidelity levels. 

8 Future Work 

We see many short-, medium-, and long-term tasks ahead of us. 
The prototype improvements already alluded to will constitute our 
short-term tasks. Specifically, we intend to incorporate adaptation 
for objects other than images in the Web application of Section 5.2. 
We also plan to add support for multiple levels of fidelity in the 
speech application of Section 5.3. 

In the medium term, we plan to enhance the prototype and gain 
experience with it in real use. First, we will broaden support for 
resource management to the full range of resources in Figure 3(c), 
and correspondingly expand the scope of our evaluation. This will 
enable Odyssey to support a broader class of applications, making 
it attractive as a platform for serious use. We then expect to deploy 
Odyssey to a small user community, and to gain empirical feedback 
to complement our evaluation through controlled experiments. 

Our long-term plans are more speculative. Currently, we expect 
to work in three broad areas: 

• The speech application of Section 5.3 suggests the importance 
of being able to dynamically decide whether to ship data or 
computation. This capability is currently provided in an ad 
hoc manner by the speech warden. Extending Odyssey to pro- 
vide full support for deciding between dynamic function or 
data shipping would enable us to more thoroughly explore this 
tradeoff in mobile computing. 

• Search of distributed repositories performs poorly when mo- 
bile because it lacks the temporal locality needed for caching 
to be effective in compensating for poor bandwidth. We plan 
to explore a solution that uses dynamic sets [35, 36] in con- 
junction with support for dynamic function versus data ship- 
ping. 

• The design of adaptive mobile systems is currently a black art. 
Developing systematic principles for their design, as well as 
techniques for analyzing their agility and stability before they 
are built, would be valuable. 



9 Conclusion 

The need for adaptation in mobile information access is now widely 
accepted. In this paper, we put forth the view that application-aware 
adaptation offers the most general and effective approach to ad- 
dressing this need. The essence of our approach is a collaborative 
partnership between applications and the system, with a clear sepa- 
ration of concerns. We argue that previous approaches to adaptation 
represent limiting cases of this general approach. 

The Odyssey architecture supports application-aware adaptation 
while paying careful attention to a variety of practical considera- 
tions. Our prototype confirms the feasibility of realizing this archi- 
tecture, and its ability to support a wide range of applications. Our 
evaluation identifies agility as a key enabling attribute of an adap- 
tive system, describes how to measure it, and reports on the agility 
of the Odyssey prototype. The evaluation confirms that the pro- 
totype does a good job of balancing performance and fidelity, and 
confirms the importance of centralized resource management. At 
the same time, it suggests avenues for further improvement. Over- 
all, Odyssey promises to be a versatile and effective platform for 
further research in mobile computing. 
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